<template><div><h1 id="如何设计一个高并发系统" tabindex="-1"><a class="header-anchor" href="#如何设计一个高并发系统"><span>如何设计一个高并发系统</span></a></h1>
<h2 id="瞬间高并发" tabindex="-1"><a class="header-anchor" href="#瞬间高并发"><span>瞬间高并发</span></a></h2>
<p>例如秒杀系统，一般只会在秒杀时间点前后5分钟左右，用户并发量才会突增，达到秒杀时间点，并发量才会达到顶峰。所以这个峰值持续的时间其实是非常短的。
像这种瞬间高并发的场景，传统的系统很难应对。可以从以下几个方面入手：</p>
<ol>
<li>页面静态化</li>
<li>CDN加速</li>
<li>缓存</li>
<li>mq异步处理</li>
<li>限流</li>
<li>分布式锁</li>
</ol>
<h3 id="_1-页面静态化" tabindex="-1"><a class="header-anchor" href="#_1-页面静态化"><span>1. 页面静态化</span></a></h3>
<p>活动页面是用户流量的第一入口，所以是并发量最大的地方。
活动页面大多数内容是固定的，比如：商品名称、商品价格，商品图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。</p>
<p>这样就能过滤大部分的无效请求。
但是只做页面静态化还不够，因为用户分散在全国各地，地域相差很远，网速也各不相同。
如何才能让用户最快访问到活动页面呢？
这就需要使用CDN，它的全程是Content Delivery Network，即内容分发网络。
当用户请求静态秒杀页面时，CDN可以让用户就近获取所需内容，降低网络拥堵，提高用户访问响应速度和命中率。</p>
<h3 id="_2-秒杀按钮" tabindex="-1"><a class="header-anchor" href="#_2-秒杀按钮"><span>2. 秒杀按钮</span></a></h3>
<p>由于大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是置灰的，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。从前面可知，该活动页面时静态的。那么我们在静态页面中如何控制秒杀按钮，只有在秒杀时间点才点亮呢？</p>
<p>没错，使用<code v-pre>JS文件</code>控制。</p>
<p>为了性能考虑，一般会将CSS、JS和图片等静态资源文件提前缓存到CDN上，让用户能够就近访问秒杀页面。</p>
<p>可是，CDN上的JS文件该如何更新呢？这问题也为难了很久。
在秒杀开始之前，JS标志为false，还有另外一个随机参数。
当秒杀开始的时候，系统会生成一个新的js文件，此时标志为true，并且随机参数生成一个新值，然后同步给CDN。由于有了这个随机参数，CDN不会缓存数据，每次都能从CDN中获取最近的JS代码。</p>
<p>此外，前端还可以加一个定时器，控制比如：10秒之内，只允许发起一次请求。如果用户点击了一次秒杀按钮，则在10秒之内置灰，不允许再次点击，等到过了时间限制，又允许重新点击该按钮。</p>
<h3 id="_3-读多写少" tabindex="-1"><a class="header-anchor" href="#_3-读多写少"><span>3. 读多写少</span></a></h3>
<p>在秒杀的过程中，系统一般会先查一下库存是否足够，如果足够才允许下单，写入数据库。如果不够，则直接返回该商品已经抢完。</p>
<p>由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。</p>
<p>这就是非常典型的：<code v-pre>读多写少</code> 的场景。</p>
<p>如果有数十万的请求过来，同时通过数据库查库存是否足够的话，那么数据库可能就要早退了，直接挂掉。因为数据库的连接资源非常有限，比如mysql，无法同时支持这么多的连接。所以，应该该用缓存，比如分布式缓存，Redis。同时还要部署多个Redis节点，保证Redis的高可用。</p>
<h3 id="_4-缓存问题" tabindex="-1"><a class="header-anchor" href="#_4-缓存问题"><span>4. 缓存问题</span></a></h3>
<p>通常情况下，我们需要在Redis中保存商品信息，里面包含：商品id、商品名称、规格属性、库存等信息，同时数据库也要有相关信息，毕竟缓存并不完全可靠。用户在点击秒杀按钮，请求秒杀接口的过程中，需要传入的商品id参数，然后服务端需要校验该商品是否合法。</p>
<p>然后根据商品id，从缓存中查询商品，如果商品存在，则参与秒杀。如果不存在，则需要从数据库中查询商品，如果数据库存在该商品，则将商品信息写入缓存，然后参与秒杀。如果数据库不存在该商品，则直接提示失败。</p>
<p>这个过程表面上看起来是OK的，但是如果深入分析一下会发现一些问题。</p>
<h4 id="_4-1-缓存击穿" tabindex="-1"><a class="header-anchor" href="#_4-1-缓存击穿"><span>4.1 缓存击穿</span></a></h4>
<p>比如有一个商品，第一次秒杀时，缓存中没有关于该商品的数据，但数据库中有。虽说上面有如果从数据库中查到数据，则写入缓存的逻辑。然而，在高并发下，同一时刻有大量的请求，都在秒杀同一件商品，这些请求同时去查缓存中有没有该数据，然后又同时访问数据库。结果悲剧了，数据库可能扛不住压力，直接挂掉。</p>
<p>如何解决这个问题呢？</p>
<p>这就需要加锁，最好还是使用分布式锁。
在查缓存时如果查不到该商品的信息，就需要获取分布式锁，再去查数据库该商品的信息，如果数据库中存在该商品信息，就写入缓存中，如果数据库中没有该商品信息，就返回失败信息，最后再去释放分布式锁。</p>
<p>当然，针对这种情况，最好在项目启动之前，先把缓存进行预热。即事先把所有的商品信息，同步到缓存中，这样商品基本都能从缓存中获取到，就不会出现缓存击穿的问题了。</p>
<p>那是不是就不需要上面加锁这一步了？</p>
<p>表面上看起来，确实可以不需要。但是如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了。如果不加锁同样可能出现缓存击穿。</p>
<p>所以这里加锁，其实就是相当于买了一份保险。</p>
<h4 id="_4-2-缓存穿透" tabindex="-1"><a class="header-anchor" href="#_4-2-缓存穿透"><span>4.2 缓存穿透</span></a></h4>
<p>如果有大量的请求传入的商品id，在缓存和数据库中都不存在，这些请求不就每次都会穿透过缓存，而直接访问数据库了。</p>
<p>由于前面已经加了锁，所以即使这里的并发量不大，也不会导致数据库直接挂掉。</p>
<p>但很显然这些请求的处理性能并不好，有没有更好的解决方案？</p>
<p>这时可以想到布隆过滤器。</p>
<p>先根据传入的商品id，在布隆过滤器中查询是否存在，如果存在，再去缓存中查询数据，如果不存在，则直接返回失败。</p>
<p>虽说该方案可以解决缓存穿透问题，但是又会引出另外一个问题：布隆过滤器的数据如何跟缓存中保持一致？</p>
<p>这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器。如果数据同步失败了，还需要增加重试机制，而且跨数据源，能保证数据的实时一致性吗？</p>
<p>显然是<code v-pre>不行</code>的。</p>
<p>所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。</p>
<p>如果缓存数据更新非常频繁，又该如何处理呢？</p>
<p>这是，就需要把不存在的商品id也缓存起来。
下次，再由该商品id请求过来，则也能从缓存中查到数据，只不过该数据比较特殊，表示商品不存在。需要特别注意的是，这种特殊缓存设置的超时时间应该尽量短一点。</p>
<h3 id="_5-库存问题" tabindex="-1"><a class="header-anchor" href="#_5-库存问题"><span>5. 库存问题</span></a></h3>
<p>对于库存问题看似简单，实则里面还是有些东西。
真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。
所以，在这里引出一个预扣库存的概念，预扣库存的主要流程如下：
<img src="@source/project-design-scenario-questions/image.png" alt="alt text" loading="lazy"></p>
<p>扣减库存中除了上面说到的预扣库存和回退库存之外，还需要特别注意的是库存不足和库存超卖问题。</p>
<h4 id="_5-1-数据库扣减库存" tabindex="-1"><a class="header-anchor" href="#_5-1-数据库扣减库存"><span>5.1 数据库扣减库存</span></a></h4>
<p>使用数据库扣减库存，是最简单的实现方案了，在通过update语句更新库存之前查一下库存是否足够，再进行更新操作。</p>
<p>但是，这里其实有个坑。</p>
<p>就是查询操作和更新操作不是<code v-pre>原子性</code>的，会导致在并发的情况下，出现库存超卖的情况。</p>
<p>这时候，聪明的人会想到说用锁，比如synchronized关键字。</p>
<p>确实，可以，但是性能不够好。</p>
<p>还有更优雅的处理方案，即基于数据库的乐观锁，这样会少一次数据库查询，而且能够天然的保证数据操作的<code v-pre>原子性</code>.
怎么做？ 在where条件后面加上<code v-pre>stock &gt; 0</code>就行了。</p>
<div class="language-SQL line-numbers-mode" data-ext="SQL" data-title="SQL"><pre v-pre class="language-SQL"><code>update product set stock=stock-1 where id=1001 and stock&gt;0;
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div></div></div><p>但是在高并发的场景下，频繁的访问数据库最终可能造成系统雪崩。而且，容易出现多个请求，同时竞争行锁的情况，造成相互等待，从而出现死锁的情况。</p>
<h4 id="_5-2-redis扣减库存" tabindex="-1"><a class="header-anchor" href="#_5-2-redis扣减库存"><span>5.2 Redis扣减库存</span></a></h4>
<p>Redis的incr方法是原子性的，可以用该方法来扣减库存。
流程如下：</p>
<ol>
<li>先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1。</li>
<li>扣减库存，判断返回值（扣减后的库存）是否小于0，如果小于0，则表示库存不足。</li>
<li>如果扣减库存后，返回值大于或等于0，则将本次秒杀记录保存起来。然后返回1，表示成功。</li>
</ol>
<p>该方案咋一看，好像没问题。</p>
<p>但如果在高并发场景中，有多个请求同时扣减库存，大多数请求的incrby操作之后，结果都会小于0.
虽说，库存出现负数，不会出现超卖的问题，但由于这里是预减库存，如果负数负的太多的话，后面万一要回退库存时，就会导致库存不准。</p>
<p>那么，有没有更好的方案呢？</p>
<h4 id="_5-3-lua脚本扣减库存" tabindex="-1"><a class="header-anchor" href="#_5-3-lua脚本扣减库存"><span>5.3 lua脚本扣减库存</span></a></h4>
<p>由于lua脚本，是能够保证原子性的，它跟Redis一起配合使用，能够解决上面的问题。</p>
<p>lua脚本有段非常经典的代码：</p>
<div class="language-text line-numbers-mode" data-ext="text" data-title="text"><pre v-pre class="language-text"><code>StringBuilder lua = new StirngBuilder();
lua.append("if (redis.call('exists',KEYS[1]) == 1) then");
lua.append("    local stock = tonumber(redis.call('get',KEYS[1]));");
lua.append("    if (stock == -1 ) then");
lua.append("        return 1;");
lua.append("     end;");
lua.append("    if (stock > 0 ) then");
lua.append("        redis.call('incrby',KEYS[1],-1)");
lua.append("        return stock;");
lua.append("     end;");
lua.append("     return 0;");
lua.append("end;");
lua.append("return -1;");
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>该代码的主要流程如下：</p>
<ol>
<li>先判断商品id是否存在，如果不存在则直接返回-1。</li>
<li>获取该商品id的库存，判断如果库存是-1，则直接返回1，表示不限制库存。</li>
<li>如果库存大于0，则incrby扣减库存。</li>
<li>如果库存等于0，则直接返回，表示库存不足。</li>
</ol>
<h3 id="_6-分布式锁" tabindex="-1"><a class="header-anchor" href="#_6-分布式锁"><span>6. 分布式锁</span></a></h3>
<p>之前在缓存击穿中提到过关于分布式锁，现在就该介绍如何实现分布式锁。</p>
<h4 id="_6-1-setnx加锁" tabindex="-1"><a class="header-anchor" href="#_6-1-setnx加锁"><span>6.1 setNx加锁</span></a></h4>
<p>使用Redis的分布式锁，首先想到的是setNx命令。</p>
<div class="language-java line-numbers-mode" data-ext="java" data-title="java"><pre v-pre class="language-java"><code><span class="token keyword">if</span><span class="token punctuation">(</span>jedis<span class="token punctuation">.</span><span class="token function">setnx</span><span class="token punctuation">(</span>lockKey<span class="token punctuation">,</span>value<span class="token punctuation">)</span> <span class="token operator">==</span> <span class="token number">1</span><span class="token punctuation">)</span><span class="token punctuation">{</span>
  jedis<span class="token punctuation">.</span><span class="token function">expire</span><span class="token punctuation">(</span>lockKey<span class="token punctuation">,</span>timeout<span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token punctuation">}</span>
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>用该命令其实可以加锁，但是和后面的设置超时时间是分开的，并非原子性操作。
假如加锁成功了，但是设置超时时间失败了，该lockKey岂不是永不失效了。在高并发场景中，该问题会导致非常严重的后果。</p>
<p>那么，有没有保证原子性的加锁命令呢？</p>
<h4 id="_6-2-set加锁" tabindex="-1"><a class="header-anchor" href="#_6-2-set加锁"><span>6.2 set加锁</span></a></h4>
<p>使用Redis的set命令，它可以指定多个参数。</p>
<div class="language-java line-numbers-mode" data-ext="java" data-title="java"><pre v-pre class="language-java"><code><span class="token class-name">String</span> result <span class="token operator">=</span> jedis<span class="token punctuation">.</span><span class="token function">set</span><span class="token punctuation">(</span>lockKey<span class="token punctuation">,</span>requestId<span class="token punctuation">,</span><span class="token string">"NX"</span><span class="token punctuation">,</span><span class="token string">"PX"</span><span class="token punctuation">,</span>expireTime<span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token keyword">if</span> <span class="token punctuation">(</span><span class="token string">"OK"</span><span class="token punctuation">.</span><span class="token function">equals</span><span class="token punctuation">(</span>result<span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">{</span>
  <span class="token keyword">return</span> ture<span class="token punctuation">;</span>
<span class="token punctuation">}</span>
<span class="token keyword">return</span> <span class="token boolean">false</span><span class="token punctuation">;</span>
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>其中：</p>
<ul>
<li>lockKey：锁的标识</li>
<li>requestId：请求id</li>
<li>NX：只有键不存在时，才对键进行设置操作</li>
<li>PX：设置键的过期时间为millisecond毫秒。</li>
<li>expireTime：过期时间。
由于该命令只有一步操作，所以它是原子操作。</li>
</ul>
<h4 id="_6-3-释放锁" tabindex="-1"><a class="header-anchor" href="#_6-3-释放锁"><span>6.3 释放锁</span></a></h4>
<p>接下来，有些朋友可能会问：在加锁时，既然已经有了lockKey锁标识，为什么要需要记录requestId呢？
答：requestId是在释放锁的时候用的。
在释放锁的时候，只能释放自己加的锁，不允许释放别人的锁。</p>
<p>这里为什么要用requestId，用userId不行吗？
答：如果用userId的话，假设本次请求流程走完了，准备删除锁。此时，锁也刚好到了过期时间失效了。而另外一个请求，巧合的使用相同的userId加锁，会成功。而本次请求删除的锁的时候，删除的其实是别人的锁了。</p>
<p>当然使用lua脚本也能避免该问题：</p>
<div class="language-text line-numbers-mode" data-ext="text" data-title="text"><pre v-pre class="language-text"><code>if redis.call('get',KEYS[1]) == ARGV[1] then
  return redis.call('del',KEYS[1])
else
  return 0
end
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>它能保证查询锁是够存在和删除锁是原子操作。</p>
<h4 id="_6-4-自旋锁" tabindex="-1"><a class="header-anchor" href="#_6-4-自旋锁"><span>6.4 自旋锁</span></a></h4>
<p>上面的加锁方法看起来没有问题，但是如果你仔细想想，如果有1万个请求同时去竞争这个锁，可能只有一个请求是成功的，其余的9999个请求都会失败。</p>
<p>在秒杀场景下，会有什么问题？
答：每1万个请求，有1个成功。再1万个请求，有一个成功。如此下去，直到库存不足。这就变成了均匀分布的秒杀了，跟我们想象的不一样。</p>
<p>如何解决这个问题呢？
答：使用自旋锁。</p>
<div class="language-java line-numbers-mode" data-ext="java" data-title="java"><pre v-pre class="language-java"><code><span class="token keyword">try</span><span class="token punctuation">{</span>
  <span class="token class-name">Long</span> start <span class="token operator">=</span> <span class="token class-name">System</span><span class="token punctuation">.</span><span class="token function">currentTimeMillis</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
  <span class="token keyword">while</span><span class="token punctuation">(</span><span class="token boolean">true</span><span class="token punctuation">)</span><span class="token punctuation">{</span>
    <span class="token class-name">String</span> result <span class="token operator">=</span> jedis<span class="token punctuation">.</span><span class="token function">set</span><span class="token punctuation">(</span>lockKey<span class="token punctuation">,</span>requestId<span class="token punctuation">,</span><span class="token string">"NX"</span><span class="token punctuation">,</span><span class="token string">"PX"</span><span class="token punctuation">,</span>expireTime<span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token keyword">if</span><span class="token punctuation">(</span><span class="token string">"OK"</span><span class="token punctuation">.</span><span class="token function">equals</span><span class="token punctuation">(</span>result<span class="token punctuation">)</span><span class="token punctuation">)</span><span class="token punctuation">{</span>
      <span class="token keyword">return</span> <span class="token boolean">true</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>

    <span class="token keyword">long</span> time <span class="token operator">=</span> <span class="token class-name">System</span><span class="token punctuation">.</span><span class="token function">currentTimeMillis</span><span class="token punctuation">(</span><span class="token punctuation">)</span> <span class="token operator">-</span> start<span class="token punctuation">;</span>
    <span class="token keyword">if</span><span class="token punctuation">(</span>time<span class="token operator">>=</span>timeout<span class="token punctuation">)</span><span class="token punctuation">{</span>
      <span class="token keyword">return</span> <span class="token boolean">false</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>
    <span class="token keyword">try</span><span class="token punctuation">{</span>
      <span class="token class-name">Thread</span><span class="token punctuation">.</span><span class="token function">sleep</span><span class="token punctuation">(</span><span class="token number">50</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span><span class="token keyword">catch</span><span class="token punctuation">(</span><span class="token class-name">InteruptedException</span> e<span class="token punctuation">)</span><span class="token punctuation">{</span>
      e<span class="token punctuation">.</span><span class="token function">printStackTrace</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>
  <span class="token punctuation">}</span>
<span class="token punctuation">}</span><span class="token keyword">finally</span><span class="token punctuation">{</span>
  <span class="token function">unlock</span><span class="token punctuation">(</span>lockKey<span class="token punctuation">,</span>requestId<span class="token punctuation">)</span><span class="token punctuation">;</span>
<span class="token punctuation">}</span>
<span class="token keyword">return</span> <span class="token boolean">false</span><span class="token punctuation">;</span>
</code></pre><div class="line-numbers" aria-hidden="true"><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div><div class="line-number"></div></div></div><p>在规定时间内，比如500毫秒内，自旋不断尝试加锁，如果成功则直接返回。如果失败，则休眠50毫秒，再发起新一轮的尝试。如果到了超时时间，还未加锁成功，则直接返回失败。</p>
<h4 id="_6-5-redission" tabindex="-1"><a class="header-anchor" href="#_6-5-redission"><span>6.5 Redission</span></a></h4>
<p>除了上面的问题之外，使用Redis分布式锁，还有锁竞争问题、续期问题、锁重入问题、多个Redis实例加锁问题等。
这些问题可以使用Redission进行解决。</p>
<h3 id="_7-mq异步处理" tabindex="-1"><a class="header-anchor" href="#_7-mq异步处理"><span>7. mq异步处理</span></a></h3>
<p>我们都知道在真实的秒杀场景中，有三个核心流程：
<strong>秒杀-&gt; 下单 -&gt; 支付</strong></p>
<p>而这三个核心流程中，真正并发量大的是秒杀功能，下单和支付功能实际并发量很小。所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成mq异步处理。而支付功能，比如支付宝支付，是业务场景本身保证的异步。</p>
<p>于是，秒杀后下单的流程变成如下：
<strong>秒杀-&gt; 发送mq消息 -&gt; mq服务端 -&gt; 消费mq消息 -&gt; 下单</strong></p>
<p>如果使用mq，需要关注一下几个问题：</p>
<h4 id="_7-1-消息丢失问题" tabindex="-1"><a class="header-anchor" href="#_7-1-消息丢失问题"><span>7.1 消息丢失问题</span></a></h4>
<p>秒杀成功了，往mq发送下单消息的时候，有可能会失败。原因有很多，比如：网络问题、broker挂了、mq服务端磁盘问题等。这些情况都有可能造成消息丢失。
那么，如何防止消息丢失呢？
答：加一张<code v-pre>消息发送表</code>就可以了。
<img src="@source/project-design-scenario-questions/image-1.png" alt="alt text" loading="lazy"></p>
<p>在生产者发送mq消息之前，先把该条消息写入消息发送表，初始状态上待处理，然后再发送mq消息。消费者消费消息时，处理完业务逻辑之后，再回调生产者的一个接口，修改消息状态为已处理。</p>
<p>如果生产者把消息写入消息发送表之后，在发送mq消息到mq服务端的过程中失败了，造成了消息丢失。</p>
<p>这时候，要如何处理呢？
答：使用<code v-pre>Job</code>，增加<code v-pre>重试机制</code>。</p>
<figure><img src="@source/project-design-scenario-questions/image-2.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>用Job每隔一段时间去查询消息发送表中状态为待处理的数据，然后重新发送mq消息。</p>
<p>其实还有一种机制：发布确认机制。</p>
<h4 id="_7-2-重复消费问题" tabindex="-1"><a class="header-anchor" href="#_7-2-重复消费问题"><span>7.2 重复消费问题</span></a></h4>
<p>本来消费者消费消息时，在ack应答时候，如果网络超时，本身就可能会消费重复的消息。但由于消费者增加了重试机制，会导致消费者重复消费消息的概率增大。</p>
<p>那么，如果解决消息重复消费问题呢？
答：加一张<code v-pre>消息处理表</code>就可以了。</p>
<figure><img src="@source/project-design-scenario-questions/image-3.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>消费者读取到消息之后，先判断一下消息处理表，是否存在该消息，如果存在，表示是重复消费，则直接返回。如果不存在，则进行下单操作，接着将该消息写入消息处理表中，再返回。</p>
<p>有个比较关键的点是：下单和写消息处理表，要放在<code v-pre>同一个事务</code>中，保证原子性。</p>
<h4 id="_7-3-垃圾消息问题" tabindex="-1"><a class="header-anchor" href="#_7-3-垃圾消息问题"><span>7.3 垃圾消息问题</span></a></h4>
<p>这套方案表面上看起来没有问题，但如果出现了消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，一直不能回调状态变更接口，这样job会不停的重试发送消息。最后，会产生大量的垃圾消息。</p>
<p>那么，如何解决这个问题呢？</p>
<figure><img src="@source/project-design-scenario-questions/image-4.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>每次在job重试时，需要先判断一下消息发送表中该<code v-pre>消息的发送次数是否达到最大限制</code>，如果达到了，则直接返回，如果没有达到，则将次数加1，然后发送消息。</p>
<p>这样如果出现异常，只会产生少量的垃圾消息，不会影响到正常的业务。</p>
<h4 id="_7-4-延迟消费问题" tabindex="-1"><a class="header-anchor" href="#_7-4-延迟消费问题"><span>7.4 延迟消费问题</span></a></h4>
<p>通常情况下，如果用户秒杀成功了，下单之后，在15分钟之内还未完成支付的话，该订单会被自动取消，回退库存。</p>
<p>那么，在15分钟内未完成支付，订单被自动取消的功能，要如何实现呢？</p>
<p>首先容易想到的是job，但是job有个问题，需要每隔一段时间处理一次，实时性不太好。</p>
<p>还有更好的方案？
答：使用<code v-pre>延迟队列</code>。
<img src="@source/project-design-scenario-questions/image-5.png" alt="alt text" loading="lazy"></p>
<p>下单时消息生产者会先生成订单，此时状态为待支付，然后会想延迟队列中发一条消息。达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。如果是待支付状态，则会更新订单状态为取消状态。如果不是待支付状态，说明该订单已经支付过了，则直接返回。</p>
<p>这有个关键点，用户完成支付之后，会修改订单状态为已支付。</p>
<figure><img src="@source/project-design-scenario-questions/image-6.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<h3 id="_8-如何限流" tabindex="-1"><a class="header-anchor" href="#_8-如何限流"><span>8. 如何限流？</span></a></h3>
<p>通过秒杀活动，如果我们运气爆棚，有可能会用非常低的价格买到不错的商品。</p>
<p>但是有些高手，并不会像我们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在自己的服务器上，模拟正常用户登录系统，跳过秒杀页面，直接调用秒杀接口。如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。</p>
<figure><img src="@source/project-design-scenario-questions/image-7.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>但是如果是服务器，一秒钟可以请求成千个接口。</p>
<figure><img src="@source/project-design-scenario-questions/image-8.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>这样就显得太不公平了。</p>
<p>所以，我们有必要识别这些非法请求，做一些限制，那么，我们该如何限制这些非法请求呢？
目前有两种常用的限流方式：</p>
<ol>
<li>基于Nginx限流。</li>
<li>基于Redis限流。</li>
</ol>
<h4 id="_8-1-对同一用户限流" tabindex="-1"><a class="header-anchor" href="#_8-1-对同一用户限流"><span>8.1 对同一用户限流</span></a></h4>
<p>为了防止某个用户，请求接口次数过于频繁，可以只针对该用户做限制。</p>
<figure><img src="@source/project-design-scenario-questions/image-9.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>限制同一个用户id，比如每分钟只能请求5次接口。</p>
<h4 id="_8-2-对同一ip限流" tabindex="-1"><a class="header-anchor" href="#_8-2-对同一ip限流"><span>8.2 对同一IP限流</span></a></h4>
<p>有时候只对某个用户限流是不够的，有些高手可以模拟多个用户请求，这种nginx就没法识别了。
这是需要加对同一IP限流功能。</p>
<figure><img src="@source/project-design-scenario-questions/image-10.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>限制同一个IP，比如每分钟只能请求5次接口。</p>
<p>但这种限流方式可能有误杀的情况，比如同一公司或网吧的出口ip是相同的，如果里面有多个正常用用户同时发起请求，有些用户可能会被限制主。</p>
<h4 id="_8-3-对接口限流" tabindex="-1"><a class="header-anchor" href="#_8-3-对接口限流"><span>8.3 对接口限流</span></a></h4>
<p>有些高手甚至可以使用代理，每次请求后都换一个IP。
这是可以限制请求接口的接口总次数。</p>
<figure><img src="@source/project-design-scenario-questions/image-11.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>在高并发场景下，这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多，达到了该接口的请求上限，而影响其他的正常用户访问接口。看起来有点得不偿失。</p>
<h4 id="_8-4-加验证码" tabindex="-1"><a class="header-anchor" href="#_8-4-加验证码"><span>8.4 加验证码</span></a></h4>
<p>相对于上面三种方式，加验证码的方式可能更精准一些，同样能限制用户的访问频次，但好处是不会存在误杀的情况。</p>
<figure><img src="@source/project-design-scenario-questions/image-12.png" alt="alt text" tabindex="0" loading="lazy"><figcaption>alt text</figcaption></figure>
<p>通常情况下，用户在请求之前，需要先输入验证码。用户发起请求之后，服务端回去验证该验证码是否正确。只有正确才允许进行下一步操作，否则直接返回，并提示验证码错误。</p>
<p>此外，验证码一般是一次性的，同一验证码只允许使用一次，不允许重复使用。</p>
<p>普通验证码，由于生成的数字或图案比较简单，可能也会被破解。优点是生成速度比较快，缺点是由安全隐患。</p>
<p>还有一个验证码叫做：移动滑块，它生成速度比较慢，但比较安全，是目前各大互联网公司的首选。</p>
<p>上面说的加验证码虽然可以限制非法用户请求，但是有些影响用户体验。用户点击秒杀按钮前，还要先输入验证码，流程显然有点繁琐，秒杀功能的流程不是应该越简单越好吗？</p>
<p>其实，有时候达到某个目的，不一定非要通过技术手段，通过业务手段也一样。</p>
<p>12306刚开始的时候，全国人民都在同一时刻抢火车票，由于并发量太大，系统经常挂。后来，重构优化之后，将购买周期放长了，可以提前20天购买火车票，并且可以在9点、10点、11点、12点等整点购买火车票。调整业务之后（当然技术也有很多调整），将之前集中的请求，一下子降低了用户并发量。</p>
<p>回到这里,我们通过提高业务门槛，比如只有会员才能参与秒杀活动，普通注册用户没有权限。或者，只有等级达到3级以上的普通用户，才有资格参与该活动。</p>
</div></template>


